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— The MAILING DATE of this communication appears on the cover sheet with the correspondence address — 
Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION: 

- Extensions of tvne may be available under the provisions of 37 CFR 1 .136 (a). In no event, however, may a reply be timely filed after SIX (6) MONTHS from the 
mailing date of this communication. 

- If the period for reply specified above is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the sat or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 1 33). 

- Any reply received by the Office later than three months after the mailing date of this communication, even rf timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1 .704(b). 

Status 

1 ) 63 Responsive to communication(s) filed on Jan 13, 2003 

2a) 63 This action is FINAL. 2b) □ This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quay/e, 1935 CD. 11; 453 O.G. 213. 

Disposition of Claims 

4) 53 Claim(s) 1 1-44 is/are pending in the application. 



4a) Of the above, claim(s) 11-15 and 22-26 
5)D Claim(s) 



6) 63 Claim(s) 16-21 and 27-44 

7) U Claim(s) 

8) D Claims 



is/are withdrawn from consideration. 

is/are allowed. 

is/are rejected. 

is/are objected to. 



are subject to restriction and/or election requirement. 



Application Papers 

9)D The specification is objected to by the Examiner. 

10)D The drawing(s) filed on is/are a) □ accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 
1 1 )□ The proposed drawing correction filed on is: a)D approved b)D disapproved by the Examiner, 

If approved, corrected drawings are required in reply to this Office action. 
12}D The oath or declaration is objected to by the Examiner. 
Priority under 35 U.S.C. §§ 119 and 120 

13)D Acknowledgement is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
a)D All b)D Some* c)D None of: 

1 . □ Certified copies of the priority documents have been received. 

2. □ Certified copies of the priority documents have been received in Application No. . 



3. □ Copies of the certified copies of the priority documents have been received in this National Stage 
application from the International Bureau (PCT Rule 17.2(a)). 
*See the attached detailed Office action for a list of the certified copies not received. 

14) D Acknowledgement is made of a claim for domestic priority under 35 U.S.C. § 1 19(e). 
a)D The translation of the foreign language provisional application has been received. 

15) D Acknowledgement is made of a claim for domestic priority under 35 U.S.C. §§120 and/or 121. 

Attachment(s) 

1 1 f)3 Notic « of References Cited (PTO-892) 4) □ Interview Summary (PTO-41 31 Paper No(s). 

2| □ Notice of Draft spsrson's Patent Drawing Review (PTO-948) 5) □ Notice of Informal Patent Application (PT0-1 521 

3) O Information Disclosure Statement(s) JPT0-1449) Paper No(s). 6) Q Other: 
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DETAILED ACTION 



1 . Claims 1 1-44 are pending. This action is in response to applicant's amendment filed 
1/13/2003. Applicant has amended claims 17 and 44. 

2. This application contains claims 1 1-15 and 22-26 drawn to an invention nonelected 
in Paper No. 14 filed 6/11/2002. A complete reply to the final rejection must include 
cancellation (by amendment) of nonelected claims or other appropriate action (37 CFR 
1.144) SeeMPEP 821.01. 

3. Claims 16, 18-20, 27, 28, 42, 43 are rejected under 35 U.S.C. 102(a) as being 
anticipated by Baxter et al (U S Pat. 6,289,500). 

As to claims 16 and 42, Baxter teaches a system (IBM San Francisco 
framework) for extending functionality (to include domain-specific functions) of a class 
object (Extensibleltem class which is domain-neutral), comprising: processing unit 
(110); system memory (120); system bus (160); computer-readable medium (155); and 
an extensible object model (San Francisco Framework) executed from, wherein the 
extensible object model creates (DomainltemCreator) an extension object 
(DomainExtension object) from an ext ension_ gackage (DomainExtension class which 
implements domain-specific functions) when a requested functionality (domain-specific 
functions) is not inherent in the class object [it is noted that the domain-neutral 
extensible items/objects do not provide domain-specific functions], and wherein the 
extension object extends the class object to provide the requested functionality (provide 
domain-specific functions to domain-neutral extensible items/objects). See col. 8, lines 
45-61 ; col. 1 0, line 1 9 - col. 1 1 , line 67. 

As to claim 18, 43, Baxter teaches registering the extension package in an 
extension database (persistent collection, col. 11, lines 16-22).. 
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As to claim 19, Baxter teaches store the extension object in system memory 
(dynamic virtual function table) when the corresponding extension is first referenced 
(col. 7, lines 20-29. 

As to claim 20, Baxter teaches creating an extension provider object (factory 
ExtensibleltemSpecialFactory) and create the extension object from the extension 
provider object (create extensions). See col. 11, lines 1-67. 

As to claim 27, Baxter teaches extensible object (Extensibleltem), extension 
database (persistent collection) having an entry for an extension (extension for a 
particular domain, ie, of type Domain Interface) for the extensible object; extension 
package (DomainExtension class and DomainltemCreator) having an interface for 
obtaining (DomainltemCreator) an extension object (DomainExtension) that provides 
the extension for the extensible object. See col. 10, line 19 - col. 1 1 , line 67. 

As to claim 28, Baxter teaches a call to the interface in the extension package 
(client call). See col. 10, lines 64-67. 

4. Claim 34 is rejected under 35 U.S.C. 102(a) as being anticipated by Graser et al 
(U S Pat. 6,275,979). 

As to claim 34, Graser teaches a method (San Francisco framework) for 
extending functionality (support additional method) of a class object (Extensibleltem) in 
a run-time environment (at run-time), comprising: receiving a request (invokeMethod()) 
from an application (client) for functionality that is not inherent in the class object [it is 
noted that Extensibleltem has no domain-specific information]; determining if the 
functionality is available (locate the method name via method table) in a first extension 
object (Extensionl); and directing the request to the functionality in a second extension 
object (Extension2), when the functionality is not available in the first extension object [It 
is noted that when looking for arb() method, Extension2 will be returned instead of 
Extensionl]. See col. 5, line 58 - col. 6, line 8; col. 6, line 30 - col. 7, line 18; col. 9, lines 
2-9; col. 11, lines 6-10. 
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5. Claims 17, 29-33, 35-41 1 44 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over the IBM San Francisco framework as disclosed by Baxter et al and 
Graser et al. 

It is noted that both Baxter and Graser describe the run-time operations of the 
same IBM San Francisco framework, emphasizing on different aspects. The 
combination of Baxter and Graser provides a more complete picture of the San 
Francisco framework. Therefore, it would have been obvious to combine the teachings 
to provide enhancement in various aspects. 

As to claim 17, IBM San Francisco framework provides (Graser) notifying the 
extensible object when the extension object is deleted (previous extension overridden 
and deleted, col. 7, lines 18-53). 

As to claim 29, the IBM San Francisco framework provides (Baxter) a method for 
extending functionality (new domain extension) of a class object (Extensibleltem) in a 
run-time environment (San Francisco framework), comprising: receiving a request from 
an application (client invokes) for functionality that is not inherent in the class object 
(new domain extension needed); determining if the functionality is available in a first 
extension object (locate special factory ExtensibleltemSpecialFactory); obtaining an 
extension package (classes, collections and factories) having computer-executable 
instructions associated with the extension object functionality (extension of type 
Domainlnterface), wherein the extension package proffers an extension provider object 
(special factory) when the functionality is requested; specifying parameters (pass 
domain parameters) to the extension provider object to create a second extension 
object (create extension object via ExtensibleltemFactory). See col. 11, lines 6-67. The 
IBM San Francisco framework also provides (Graser) a step for directing the invocation 
to the second extension object (Extension2 which implements the requested arbQ) after 
the second extension object has been created. See col. 5, line 58 - col. 6, line 8; col. 6, 
line 30 - col. 7, line 18; col. 9, lines 2-9; col. 11, lines 6-10. 

As to claim 30, note discussion of claim 1 8. 



Serial Number 09/240,406 - 5 - 

Art Unit 2151 

As to claims 31, 36, note discussion of claim 27 (Baxter) for storing the extension 
package in an extension database. 

As to claims 32, 40, San Francisco framework provides (Graser) searching for an 
entry associated with the functionality (col. 6, lines 9-41). 

As to claims 33, 41, San Francisco framework provides (Graser) creating the 
second extension object when the extended functionality is first referenced (create new 
extension and add to method table), and locating (look up method name) the second 
extension object when the extended functionality is subsequently referenced (col. 6, 
lines 9-65). 

As to claim 35, note discussion of claim 29 for obtaining an extension package. 
As to claim 37, note discussion of claim 18. register the extension package in an 
extension database stored on. 

As to claims 38 and 39, note discussion of claim 20. 

As to claim 44, the IBM San Francisco framework provides (Baxter) a method for 
extending functionality (new domain extension) of a class object (Extensibleltem which 
is domain-neutral), comprising: invoking (client invokes) a functionality that is not 
inherent in the class object (new domain extension); determining if the invoked 
functionality is available in a first extension object (look for special factory 
ExtensibleltemSpecialFactory that should be used); creating a second extension object 
(use standard factory ExtensibleltemFactory) when the invoked functionality is not 
available in the first extension object (otherwise use the standard factory). See col. 1 1 , 
lines 1-11, 39- 50. The IBM San Francisco framework also provides (Graser) a step for 
directing the invocation to the second extension object (Extension2 which implements 
the requested arb()) after the second extension object has been created. See col. 5, 
line 58 - col. 6, line 8; col. 6, line 30 - col. 7, line 18; col. 9, lines 2-9; col. 11, lines 6-10. 

6. Claim 21 is rejected under 35 U.S.C. 103(a) as being unpatentable over Baxter 
et al as applied to claim 16 and in view of Schmidt et al ("An Object-Oriented 
Framework for Developing Network Server Daemons"). 
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As to claim 21 , Schmidt teaches framework based software architecture (service 
configuration), including creating an event filtering and sourcing object (event handler) 
to handle events (events) generated by an extension object (service object). See pages 
7-8, section 4.1. Therefore, it would have been obvious to create an event filtering and 
sourcing object in Baxter to handle events generated by an extension object. In so 
doing, configuring different types of I/O events from a client would have been simplified 
with the class library (page 6, section 3.2.3). 



7. Applicant's arguments filed 1/13/2003 have been fully considered but they are 
not persuasive. 

Regarding Baxter, applicant argued that (1) Baxter's process does not include 
considering the inherent functionality in the class object and then looking to an 
extension package when that functionality is not inherent in the class object (page 4, 
2nd paragraph), (2) Baxter creates an architecture that enables customization of an 
application, whereas the present invention permits extension objects from one vendor's 
application to be available to another vendor's application and extends methods and/or 
properties of an object residing at any level in an application through an extension 
object (page 3, last paragraph - page 5, 1st paragraph). 

The examiner respectfully disagrees. As to (1), first, the claim language does not 
require a separate step of determining/considering whether a requested functionality is 
inherent in the class object prior to looking. Instead, the claim language either does not 
describe the inherency aspect of a requested functionality at all (see for example claim 
27), or describe the inherency aspect as already known to be not inherent in the class 
object (see for example, claims 16/42: "the extensible object model causes the 
processing unit to create an extension object from an extension package when a 
requested functionality is not inherent in the class object (lines 8-1 0); claims 29/34/44: 
"receiving a request from an application for functionality that is not inherent in the class 
object 1 ). Second, in Baxter, by definition, domain-neutral extensible items/objects do 
not provide domain-specific functions. Thus a requested functionality being a domain- 
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specific function is not inherent in the class object / Extensibleltem class (which is 
domain-neutral). In other words, Baxter considers the inherency in the class object by 
determining that a requested function is a domain-specific function/extension before 
locating/creating such function/extension. See col. 1 1 , lines 6-67. 

As to (2), the architecture of Baxter is an object infrastructure which provides 
dynamic run-time extension of object support. See Baxter, col. 5, line 61 - col. 6, line 
15. In other words, it is an extensible object model. Further, as disclosed, the extensible 
object model refers to an application. Application as filed, page 9, lines 8-9. Regarding 
the argued 'extension objects from one vendor's application', 'another vendor's 
application' and 'methods and/or properties of an objectj^sj ^g^t,anyJev eUnjn 
application', these features have not been brought out by the claim language, nor do 
they appear to be disclosed in the application as filed. 



~ No arguments in substance were provided in the response filed regarding Graser 
and Schmidt. Presumably applicant agrees with the interpretations of Graser and of 
Schmidt detailed in the last Office action. 

For these reasons, applicant's arguments are not persuasive. 

8. THIS ACTION IS MADE FINAL Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for response to this final action is set to expire 
THREE MONTHS from the date of this action. In the event a first response is filed 
within TWO MONTHS of the mailing date of this final action and the advisory action is 
not mailed until after the end of the THREE-MONTH shortened statutory period, then 
the shortened statutory period will expire on the date the advisory action is mailed, and 
any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date 
of the advisory action. In no event will the statutory period for response expire later 
than SIX MONTHS from the date of this final action. 
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9. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Sue Lao whose telephone number is (703) 305-9657. A 
voice mail service is also available at this number. The fax phone numbers for the 
organization where this application or proceeding is assigned are (703) 746-7238 for 
After Final communications, (703) 746-7239 for Official communications and (703) 746- 
7240 for Non-Official/Draft communications. 

Any inquiry of a general nature or relating to the status of this application or 
proceeding should be directed to the Group receptionist whose telephone number is 
(703) 305-9600. 



Sue Lao 
March 10, 2003 



